A variety of applications advantageously perform transfers of data in a so-called "streaming" environment. In general, such transfers are accomplished with a series of modules that sequentially operate to pass data from an inbound stream (i.e., a "read" stream) to an outbound stream (i.e., a "write" stream), in this way moving the data along the prescribed stream. Such transfers of data are useful in applications including web servers (i.e., "exit" routines), servlet extensions (i.e., a potentially emerging Internet model), and other streaming environments having equivalent functionality. In practice, however, such methods have been found to exhibit certain limitations.
For example, one known practice for implementing a streaming environment is to use a basic (i.e., "trivial") approach in which data is exhaustively obtained from the read stream (or read "pipe") and then written to the write stream (or write "pipe"). This process is then followed by the writing of any new data to the write stream (i.e., down the write pipe). This solution has the disadvantage, however, that all transferred data must be copied from the read pipe to the write pipe for each of the transfers made between the plural modules which comprise the data transfer system. This leads, in turn, to an adverse system overhead which limits the efficiency and, accordingly, the overall data transfer rate that can be established using such a system.
Another known practice for implementing a streaming environment is used with CMS (conversational monitor system) pipelines. In conjunction with the operation of a CMS pipeline, a method (i.e., the so-called "SHORT" method) is provided that allows a given stage of the pipeline to connect the inbound stream directly to the outbound stream. Although this method helps to increase the efficiency of the resulting system, such a method lacks the ability to append data to the outbound stream after the data received from the inbound stream has been exhausted.
Also to be considered is that the model used by CMS pipelines is record based and, therefore, quite different from the desired model in which data is to be sequentially transferred in a way that minimizes the performance and system resource penalties associated with the copying of data as that data is transferred from module to module. Further, after exhausting its read source, each module must have the ability to write to the outbound pipe.
Therefore, the primary object of the present invention is to provide a module useful in a streaming environment that can pass data from the inbound stream to the outbound stream in a way that minimizes the performance and resource penalties associated with the copying of data. Another object of the present invention is to provide a module useful in a streaming environment that can efficiently pass data from the inbound stream to the outbound stream and that has the ability to return control to the module during the data transfer function. Still another object of the present invention is to provide a module useful in a streaming environment that can efficiently pass data from the inbound stream to the outbound stream and which, after exhausting the read source, has the ability to write additional data to the outbound pipe.